The Diameter Credit-Control Application (DCCA) is a well-known protocol that supports real-time charging for time units, volume units of uploaded or downloaded data, or the like, that are purchased by network subscribers through their use of network-provided services. Communications subject to the protocol are typically conducted between a gateway or control point as client, and an online charging system as server. The Diameter Credit-Control Application has been standardized in the IETF specification designated RFC 4006. The Diameter base protocol has been standardized in the IETF specification designated RFC 3588.
At the start of a subscriber session, and during the session, the client requests service units and the server grants service units by means of a message flow between the client and the server. In the CCR (Credit Control Request) message, the client requests a grant of some number of service units, and it may report on the number of units that have been used. The CCR message may also include a request to initiate or terminate the session.
In many communication networks, particularly LTE networks, the router that effectuates a wireless provider's connection to the Internet is referred to as the PDN Gateway (PGW). Accordingly, in FIG. 1 the client in this regard is PGW 10, and the server is Line Server 20. Below, we will use the term “RTR” interchangeably with “line server”.
In the CCA (Credit Control Answer) message, the server responds with a grant of service units or with a rejection if, e.g., the account has been exhausted. The CCA may also include a statement of the remaining balance of credit units, and it may include a statement of the amount of time during which the current quota is valid. When the quota times out, the client renews the credit control request by sending a CCR-U (CCR Update) message, to which the server responds with a CCA-U (CCA Update) message.
Two further messages are Re-Authentication Request (RAR) and Re-Authentication Answer (RAA). The server, e.g. Line Server 20 of the figure, sends an RAR message to the client to request reauthentication or reauthorization of the client. The client, e.g. PGW 10 of the figure, responds by sending an RAA message to the server, followed by an authentication or authorization message.
It has recently become a widespread practice for networks to offer data download services and the like for pluralities of users or terminal devices that have been joined together in user groups. The accounting and charging for such services is often managed by a group server that is functionally part of the online charging system. Such a group server is illustrated as element 30 of FIG. 1, where it is shown as part of online charging system (OCS) 35.
Each individual user or terminal device that is being served is referred to here as one of the group of “lines” served by the group server. With further reference to FIG. 1, it will be understood that one line is constituted, in part, by Line Server 20 and PGW 10, and that other lines are likewise constituted by Line Servers 21, 22, and 23, with their respective PGWs 11, 12, and 13. Each such line is said to have a network end represented in the figure by the PGW and an OCS end represented in the figure by the line server.
Through messaging, the group server and line servers can regulate the usage of service units by the group, as well as by individual members of the group, in the downloading of data.
An illustrative exchange of such messages is illustrated in the signaling diagram of FIG. 2, in which elements having correspondences in FIG. 1 are denoted by like reference numerals. In the figure, it will be seen that after a new line served by PGW 10 has been added to the group, PGW 10 sends an initial CCR, i.e., CCR-I 41, to line server 20 to request a new session. The line server responds with the acknowledgement message CCA-I 42. In the CCA-I message, the line server assigns a quota of service units to the PGW. When the line has consumed its initial quota, or when the initial quota has timed out, PGW 10 sends an updated CCR message, i.e., CCR-U 61, reporting the consumed quota. The line server responds with acknowledgement message CCA-U 62, in which a new quota is assigned.
In response to a Session Parameter Update message (to be discussed below) from Group Server 30, the line server initiates the Session Reauthorization procedure by sending RAR message 81 to the PGW. The PGW acknowledges by sending RAA message 82 to the line server. RAR messages cause the PGWs that receive them to issue CCR-U messages reporting consumed quota and to request new quota allocations. Accordingly, in our illustration PGW 10 then sends a new CCR update message, i.e., CCR-U 91 to the line server. The line server responds with CCA-U message 92, in which a new quota is assigned.
One drawback of the protocol described above is that as the size of the user group grows, the amount of messaging required for managing the quotas can grow enough to significantly affect the profitability of the network. There is therefore a need for methods of quota management that use messaging more efficiently.